Death care management system and method

ABSTRACT

A system that provides automated and semi-automated tools and methods that may be used by providers in the death care industry to manage time sensitive tasks and share information with third party providers of goods and services.

PRIORITY

This application is a continuation of, and claims the benefit of, U.S.Non-Provisional patent application Ser. No. 15/079,189, filed on Mar.24, 2016, which itself is a non-provisional of, and claims the benefitof, U.S. Provisional Patent Application Ser. No. 62/138,656, filed Mar.26, 2015, entitled “Death Care Management System and Method.” Each ofthose applications is hereby incorporated by reference in its entirety.

FIELD

The disclosed technology pertains to a system for managing tasks andtransactions relating to death care.

BACKGROUND

There are more than 22,000 funeral homes in the United States, with manybeing independently or family owned. Many of these independent funeralhomes have processes for managing tasks and transactions relating tofunerals that have developed over decades of business, though oftenthese processes fail to leverage modern technologies effectively. As aresult, the execution of a perfect funeral often relies upon dry eraseboards, whiteboards, handwritten paper order forms, fax machines, andtelephone calls. For example, in many funeral homes the planning,preparation, and scheduling of funeral services are managed by writingout tasks on a whiteboard and checking off or filling in information astasks are completed. The whiteboard could include information about areserved location for visitation, police escorts for a procession, atailor hired to prepare burial garments, or even a hired hairdresser.While such a process is often adequate, there is a significant chancefor error due to smudged or accidentally erased information, informationwritten into the wrong column, or simply forgetting to add or remove atask or related information.

As another example, in many funeral homes the management and tracking oftransactions between funeral homes and third parties that provide goodsand services relating to a funeral is inconsistent or even non-existent.A funeral home might have several different vendors that provideconcrete vaults for burial services. One vendor might accept orders andprovide updates by email, another might accept orders via fax andprovide updates by mail, yet another might accept order via phone andprovide no updates unless requested. With no consistency in the mannerthat each vendor accepts and communicates about orders, the funeral homeis in a position where it must adapt its processes to match aninconsistent and unreliable set of third party processes. However, it isnot uncommon for a funeral home to be waiting on an update for shipping,having forgotten that the vendor they ordered the vault from does notprovide shipping updates. Even worse, in some cases a funeral home maybelieve that they ordered a vault via phone or email when in fact theorder was never received or recorded by the vendor, and, due toinconsistent practices in providing order updates, the error may not berealized until it is too late to have a vault ready for the burialceremony.

What is needed, therefore, is an improved system for managing tasks andtransactions related to death care.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings and detailed description that follow are intended to bemerely illustrative and are not intended to limit the scope of theinvention as contemplated by the inventors.

FIG. 1 is a flowchart of a set of exemplary high-level steps that asystem could perform to manage transactions relating to death care.

FIG. 2 is a flowchart of a set of exemplary steps that a system couldperform to receive transactions from a client.

FIG. 3 is a flowchart of a set of exemplary steps that a system couldperform to receive information from a vendor and deliver it to a client.

FIG. 4 is a flowchart of a set of exemplary steps that a system couldperform to receive information from a vendor and deliver it to a client.

FIG. 5 is a flowchart of a set of exemplary steps that a system couldperform to receive information from a vendor and deliver it to a client.

FIG. 6 is a flowchart of a set of exemplary high-level steps that asystem could perform to manage and display tasks relating to death care.

FIG. 7 is a flowchart of a set of exemplary steps that a system couldperform to receive and react to external event information.

FIG. 8 is a flowchart of a set of exemplary steps that a system couldperform to receive and react to task updates.

FIG. 9 is a flowchart of a set of exemplary steps that a system couldperform to manage task priorities over time.

FIG. 10 is a schematic diagram of an exemplary system configured tomanage tasks and transactions related to death care.

FIG. 11 is a screen capture showing an exemplary interface for viewingand interacting with tasks related to death care.

FIG. 12 is a screen capture showing an exemplary interface for viewingand interacting with tasks related to death care.

FIG. 13 is a screen capture showing an exemplary interface for viewingand interacting with tasks related to death care.

FIG. 14 is a screen capture showing an exemplary interface for viewingand interacting with tasks related to death care.

FIG. 15 is a screen capture showing an exemplary interface for viewingand interacting with tasks related to death care.

FIG. 16 is a screen capture showing an exemplary interface for viewingand interacting with tasks related to death care.

FIG. 17 is a screen capture showing an exemplary interface for viewingand interacting with tasks related to death care.

FIG. 18 is a screen capture showing an exemplary interface for viewingand interacting with tasks related to death care.

FIG. 19 is a screen capture showing an alternate interface for viewingand interacting with tasks and events related to death care.

FIG. 20 is a screen capture showing an alternate interface for viewingand interacting with tasks and events related to death care.

FIG. 21 is a schematic diagram of an alternate exemplary systemconfigured to manage tasks and transactions related to death care.

DETAILED DESCRIPTION

The inventors have conceived of novel technology that, for the purposeof illustration, is disclosed herein as applied in the context of asystem for managing tasks and transactions relating to death care. Whilethe disclosed applications of the inventors' technology satisfy along-felt but unmet need in the art of death care management systems, itshould be understood that the inventors' technology is not limited tobeing implemented in the precise manners set forth herein, but could beimplemented in other manners without undue experimentation by those ofordinary skill in the art in light of this disclosure. Accordingly, theexamples set forth herein should be understood as being illustrativeonly, and should not be treated as limiting.

Turning now to the figures, FIG. 1 shows a flowchart of a set ofexemplary high-level steps that a system, such as the exemplary systemshown in FIG. 10, could perform to manage transactions relating to deathcare. In FIG. 10, a management server (1000) is communicatively coupledwith a database (1002) and is configured to expose a Whiteboard service(1012) and a Connect service (1004) to users via a wide area network orother communication means. The management server (1000) may be one ormore physical servers, virtual servers, computers, or other computingdevices allowing for the processing and communication of data. Thedatabase (1002) may be one or more local databases, remote databases,distributed databases, physical storage drives, cloud storage drives, orother data structures or devices allowing for the storage and retrievalof data. The Whiteboard and Connect services (1012, 1004) may comprise,for example, websites, web services, or other similar interfacesaccessible via, for example, web browser, application, HTTP, FTP, orother communication tools and standards. External users may interactwith the Whiteboard service (1012) via, for example, a computer (1014)web browser, application, or other tool, mobile device (1016) webbrowser, application, or other tool, interactive smart-board orwhiteboard (1018) web browser, application, or other tool, or othersimilar devices and tools. The Whiteboard service (1012) provides accessto tools and methods that aid in managing tasks related to death care.External users may interact with the Connect service (1004) via, forexample, a computer (1006) web browser, application, or other tool,mobile device (1010) web browser, application, or other tool, existingvendor system (1008) application or web service, or other similardevices and tools. The Connect service (1004) provides access to toolsand methods that aid in managing transactions related to death care. Forexample, a funeral home client may order or reserve various goods andservices from participating vendors through the Connect service (1004),which will manage the communication and tracking of the transaction.

The system of FIG. 10 may register clients (100), register goods vendors(102), or register service vendors (104). In some embodiments, thesystem may also allow registration of other entity types. For example, adata provider may register with the system and provide data to thesystem via the connect service (1004). Data provided may includeanalytics data for services, products, vendors, venues, or otherinformation. For example, data provided may include informationdescribing customer satisfaction, timeliness, costs of one or morehairdressing services, and/or various other kinds of data associatedwith various kinds of death care products and services. Data consumersmay also register with the system in order to consume various types ofdata. Consumed data may include high level de-identified analytics data,such as average time or cost for different services, average cost forproducts, or other analytics. Consumed data may also include vendorspecific data, such as timeliness and satisfaction levels for one ormore vendors. Consumed data may contain data provided by data providers,as well as data generated through user interactions with the connectservice (1004) and whiteboard service (1012). For example,communications and updates on services and goods passed through theconnect service (1004) may be used to generate high level dataindicating the length of time it takes to perform a service or receive agood. As another example, user interactions with the whiteboard service(1012), such as adding, updating, and closing tasks, may be used togenerate high level data indicating the quality and timeliness ofservices provided by funeral homes in a region.

Registration may be performed by, for example, receiving informationsubmitted via a user device (1006, 1008, 1010, 1014, 1016, 1018) or bymanual configuration via the management server (1000). Informationprovided during registration could include identifying information forthe client or vendor such as name, address, and type of business,contact information and preferences such as phone number or emailaddress, and authentication information such as usernames, passwords,and configurations settings that may be required to communicate with thesystem via an existing vendor system, a web service, API, or otherinterface. For example, one vendor or client may register with thesystem and choose their primary method of interacting with the system tobe a website or mobile phone application. This may be a good choice fora vendor or client that does not have an existing sophisticated system(1008) to manage their transactions, but does have access to computers(1006) or mobile devices (1010). This preference, as well as a usernameand password unique to that user could be provided during registration.

As another example, one vendor or client may register with the Connectservice (1004) and choose their primary method of interacting with thesystem to be via a web service or API that communicates with an alreadyexisting vendor or client system (1008). In this manner, the Connectservice (1004) can interact with an existing client system (1008)through direct communication via an API or web service, rather thanreplacing it entirely. This may be a good choice for a vendor or clientthat has already has a computer system in place that managestransactions internally. Alternately, an existing client system (1008)may be an existing website where the vendor allows clients to manuallypurchase goods or reserve services. In such a case, the Connect service(1004) may interact with the existing client website through browserautomation tools that could allow the Connect service (1004) toautomatically reserve services or order goods through the vendorwebsite. This preference, as well as authentication and identificationinformation that will allow the client system (1008) to interact withthe Connect service (1004) could be provided during registration. As yetanother example, one vendor or client may register with the Connectservice (1004) and choose their primary method of interacting with theservice to be via automated phone call or text. This may be a goodchoice for a vendor or client that would like to minimize thetechnological requirements for using the Connect service (1004). Thispreference, as well as one or more contact phone numbers could beprovided during registration.

Upon registration (100, 102, 104) of a client and vendor, a transactionmay be received (106) from a client indicating that a client hasrequested services or goods from a vendor. By using the storedcommunication preferences and information for a vendor, the Connectservice (1004) can notify the vendor of the transaction via theirpreferred method and request that the vendor confirm receipt andacceptance of the transaction (108). For example, for some vendors thisnotification could be delivered via a website or email, and confirmationcould be requested by offering a clickable button at the website or aformatted email reply. For other vendors, this notification could occurby entering the transaction directly into the existing vendor system(1008) via a web service or API and requesting an automaticallygenerated invoice or confirmation. For other vendors, this notificationcould occur by automated phone call or text message, and confirmationrequested via an automated phone menu system or via formatted textmessage response. When a vendor confirms the transaction, whether bywebsite, email, web service, API, phone, text, or other communication,the system received the vendor confirmation (110) and then notifies theclient (112) via the clients preferred method of contact, which could bewebsite, email, web service, API, phone, text or other communication. Insome embodiments, the communication between client and vendor couldoccur through multiple communications rather than just one, such thatone vendor could be notified (108) via both website and text, and couldsimilarly confirm the transaction (110) via website or text. Similarly,in some embodiments, clients could receive notifications (112) via oneor more configured communication preferences.

Once a transaction has been confirmed (110) and the client has beennotified (112), the transaction can be managed throughout one or morestages while the involved goods and services are prepared until thetransaction is complete (114) and the transaction can be successfullyclosed (120). While the transaction is not complete (114), the servicemay request one or more vendor updates (116) from the vendor, via theconfigured communications preferences, and receive one or more vendorupdates (118) in response, via the configured communication preferences,in each case notifying the client (112) of the vendor update (118), alsovia the configured communication preferences. As an example, where anorder for a concrete burial vault has been received (106) by the Connectservice (1004), passed to the vendor (108), and confirmed by the vendor(110), the transaction would not be complete (114) until the successfuldelivery of the concrete burial vault. Before delivery and completion ofthe transaction (114), the system may automatically request one or morevendor updates (116) related to the transaction, with the number andtype of requests varying based upon the goods or services associatedwith the transaction. In the case of a concrete burial vault, theservice may request a vendor update when the burial vault is ordered,when shipment of the burial vault begins, and when delivery of theburial vault is completed. In each case of a vendor request (116), avendor update, such as confirmation that the vault has been created, ordelivered, is received by the service (118) and passed to the client asa notification (112).

Turning now to FIG. 2, that figure shows a flowchart of a set ofexemplary steps that a system could perform to receive transactions fromand/or for a client (106). Transactions from a client may be receivedvia, for example, web service or API (200) when received from anexisting client system (1008) or application, mobile application orwebsite (202), email (204), automated phone menu or text menu (206), orother communication methods. In some embodiments, validation of thetransaction may occur upon receipt (208). Validation could includeverification that all required information is present and conforms tovalidation rules, such as confirming that a supplied address includesboth characters and integers, or confirming that a supplied price onlyincludes integers. If the transaction fails one or more validationrules, the transaction will not be entered (210) and a notification willbe sent to the client and system administrators detailing thedeficiency. In some embodiments, certain deficiencies in a transactionmay be automatically addressed by the service. For example, where novendor is initially selected (212) when submitting the transaction, thesystem may automatically select a vendor (214) that supplies therequested goods or services within the requested area or region. Othertypes of deficiencies may be automatically addressed by the servicewhere it is deemed to be convenient for the client to quickly registertransactions and where the automatically corrected deficiency is not ofcritical importance to the client. Where a vendor is initially selectedfor the transaction, or where there is no deficiency, the transactionwill be entered (216) by the service.

Turning now to FIG. 3, that figure shows a flowchart of a set ofexemplary steps that a system could perform to receive information froma vendor (110) and deliver it to a client (112). While shown in thecontext of a vendor receiving a request for confirmation and providingconfirmation to a client, the same general method can be applied to anycommunication between client and vendor, such as requesting vendorupdates (116), receiving vendor updates (118) and notifying a client(112). As shown in FIG. 3, when a transaction is entered (216), theservice will identify one or more methods of communication enabled forthe vendor associated with the transaction. If the vendor may becommunicated with via API or web service (300), the transactionnotification may be provided to the vendor using the configurationprovided during registration that will allow the transaction to bedirectly submitted to the vendor system (1008) via an available API orweb service (302). Vendor confirmation of the transaction may then bereceived by the system (304) via the available API or web service.Vendor confirmation may be automatically generated by the vendor system(1008) or manually generated by a vendor after time for review.

If the vendor may be communicated with via application, mobileapplication, or website (306), the transaction notification may beprovided to the vendor using a website, application, or mobileapplication (308). Vendor confirmation of the transaction may then bereceived by the system via the website, application, or mobileapplication (310). Vendor confirmation may be automatically generatedbased upon vendor configuration of a website, application or mobileapplication, or manually generated in response to a notificationreceived via a website, application, or mobile application. For example,in the case of a mobile application, the service may cause anotification message or sound to occur on a vendor mobile device (308).The notification on the vendor mobile device may be viewed and may offera button or other interactive element that the vendor may interact withto cause a confirmation to be generated and received by the service(310). Notification and receipt via a web site or application couldoccur similarly.

If the vendor may be communicated with via email (312), the transactionnotification may be provided to the vendor via email (314). Vendorconfirmation may be automatically generated by configured emailresponses, or may be manually generated by a vendor in response to anemail and received by the service (316). In the case of manualgeneration of a vendor confirmation, the email notification (314)provided to the vendor may be formatted such that a reply withadditional pre-defined information entered into the subject line or bodyof the email may be received by the service (316) and automaticallyinterpreted based upon the known formatting.

If the vendor may be communicated with via phone or text (318), thetransaction notification may be provided to the vendor via phone or text(320). Notification via phone may be in the form of an automated phonecall, while notification via text may be in the form of a text messageor text message and attached image or file. Vendor confirmation may begenerated manually by the vendor in response to a call or text and maybe received by the service via phone or text (322). For example, anautomated phone call notifying a vendor (320) of a transaction maydeliver a voice messages describing the pertinent details of thetransaction, and then prompt the answering vendor to press one or morekeys to confirm the transaction, modify the transaction, refuse thetransaction, or attempt to immediately call the client for furtherdiscussion. Such confirmation or other response will be received by theservice (322) via the automated phone call. In the case of a textmessage, the text message notification (320) may contain text or imagesdescribing the pertinent details of the transaction, and prompt thereceiving vendor to reply with one or more defined responses that, whenreceived by the service (322), will indicate confirmation of thetransaction, refusal of the transaction, modification of thetransaction, or a need for follow up by phone for further discussion.

When confirmation or communication intended for a client has beenreceived from a vendor, the service may determine from registrationinformation whether the client the notification is intended for may becommunicated with via API or web service (324). If the client isconfigured for communication via API or web service, the vendorconfirmation or communication may be provided to the client via API orweb service (326) and entered directly into the client's existing system(1008) or other system. If the client is not configured forcommunication via API or web service (324), or if the client prefersmultiple types of communication, the service may determine whether thevendor confirmation or communication may be provided to the client viaapplication or website (328). If the client is configured forcommunication via application or website (328), the vendor confirmationor communication may be provided to the client via application, mobileapplication, or website (330). If the client is not configured forcommunication via application or website (328), or if multiplecommunication types are configured, the service may determine whetherthe vendor communication may be provided via email (332). If the clientis configured for email communication (332), the notification orcommunication may be provided via email (334). If the client is notconfigured for email communication (332), the service may determinewhether the communication may be provided via phone or text (336). Ifthe client is configured for phone or text communication (336), thecommunication may be provided via automated phone call or text (338).While FIG. 3 shows several types of configurable communicationpreference for both vendors and clients, other communication types existthat can be added or substituted into the steps of FIG. 3.

Turning now to FIG. 4, that figure shows a flowchart of a set ofexemplary steps that a system could perform to receive information froma vendor and deliver it to a client. For example, the steps of FIG. 4could be used as part of a method for requesting (116) and receiving(118) vendor updates for client notification (112) from a vendor ofgoods while the providing of goods is not yet complete (114). When goodshave been ordered (400), the client may desire to receive regularupdates up to the moment that the goods are delivered. Such updatescould include, for example, information relating to production of thegoods (402), information relating to shipping of the goods (408), orinformation relating to the delivery of the goods (414). When a clienthas ordered goods, and has not yet received information relating to theproduction of the goods (402), a request for information relating to thecreation or production of the goods can be provided to the vendor (404).Such a request might be for information relating to the time thatmanufacturing of the goods was started or the time that the goods areestimated to be completed. Requested production information may bereceived (406) from the vendor and provided to the client (420). Therequest and communication of the information may be communicated to thevendor, received from the vendor, and provided to the client by usingsteps similar to those shown in FIG. 3. Requests for information may begenerated automatically by the service based upon a configured scheduleor manually by a client.

When shipping information has not yet been provided (408), a request forshipping information may be generated and communicated to the vendor(410). Received shipping information (412) may then be provided to theclient (420). Similarly, when delivery information has not yet beenprovided (414), a request for delivery confirmation may be generated andprovided to the vendor (410). Received delivery information (418) maythen be provided to the client (420). As an example, when a concreteburial vault has been ordered (400), the service may be configured toautomatically generate a request for creation information (404) twentyfour hours after order confirmation. The vendor may receive the requestand provide an information update via any of the described communicationmethods. The information received (406) may indicate that the concreteburial has been created and is currently awaiting shipment. In thismanner, the client can quickly receive information that provides themthe confidence that the burial vault has been created without having tocall and speak to someone directly. Various other types of informationrelating to the purchase and delivery of goods may be added orsubstituted into the steps of FIG. 4 beyond those shown.

In some versions, ordered goods could be marked with unique identifierssuch as barcodes or other optical codes, or tagged with wirelessidentifiers such as NFC or RFID chip identifiers. Once a particularordered good is associated with a unique identifier, identification ofthe goods can be performed in a semi automated manner using a userdevice with appropriate capabilities to scan and receive informationfrom the optical or wireless identifier. For example, when a coffin isordered for a particular decedent, the order will be associated withthat decedent in a database. When the coffin is produced, a uniqueidentifier will be marked or placed on the coffin and also associatedwith the decedent. After being associated with a unique identifier, auser device, such as a mobile phone or other handheld device can be usedto interact with the unique identifier via an optical scanner orwireless communicator. This could be useful to, for example, use amobile phone to scan a coffin and automatically transmit creationinformation for the coffin to be received (406) by the system, scan acoffin and automatically transmit shipping information to be received(412) by the system, scan a coffin and automatically transmit deliveryinformation to be received (418) by the system, or similar informationsharing steps. Additionally, such a unique identifier being physicallyassociated with the coffin could be useful at other times foridentification purposes. For example, a user may scan a coffin toquickly and accurately identify a decedent or burial service that thecoffin is associated with at different points during preparation andperformance of a burial service, to ensure that the correct coffin isbeing transported to the visitation site, and then to the cemetery.

Turning now to FIG. 5, that figure shows a flowchart of a set ofexemplary steps that a system could perform to receive information froma vendor and deliver it to a client. For example, the steps of FIG. 5could be used as part of a method for requesting (116) and receiving(118) vendor updates for client notification (112) from a vendor ofservices while the performance of the services is not yet complete(114). When services have been requested (500), the client may desire toreceive regular updates until the performance of the services iscomplete. Such updates could include, for example, a confirmation beforethe services begin (502), a notification that performance of theservices has begun (508), or a notification that performance of theservices has been completed (514). When a pre-service confirmation hasnot yet been received (502), a request for confirmation may be generatedand provided to the vendor (504). This may be useful where a hairdresseris scheduled to perform services several days in the future, so that aclient may request confirmation twelve or twenty four hours before thescheduled date that the hairdresser is still available and planning toperform the services. A received confirmation of the services (506) maythen be provided to the client (520). The request and communication ofthe information may be communicated to the vendor, received from thevendor, and provided to the client by using steps similar to those shownin FIG. 3. Requests for information may be generated automatically bythe service or manually by a client.

When service start information has not yet been provided (508), servicestart information can be requested (510) and received (512) by theservice and provided to the client (520). When service completioninformation has not yet been provided (514), service completioninformation can be requested (516) and received (518) by the service andprovided to the client (520). As an example, when a hairdresser has beenreserved to perform services at a certain time, a confirmation may beautomatically generated and provided to the hairdresser twelve hoursbefore the scheduled service via one of the communication methodsalready described (504). The hairdresser may confirm that they are stillavailable and planning to provide the service via one of the describedcommunication methods, which the system may receive (506) and provide tothe requesting client (520). Similarly, a request for service startinformation may be generated at the scheduled start time (510), and arequest for service completion information may be generated at theestimated completion time. In each case, the service may receive therequested information (512, 518) and provide it to the client (520). Inthis manner, a requesting client may receive a steady stream ofinformation so that they can be confident that the services areprogressing to completion without having to personally or manuallyintervene or request information.

As with goods, the integration of a unique identifier such as an opticalidentifier or a wireless identifier like an RFID or NFC chip may be usedto aid in the semi-automatic tracking and updating of services. Forexample, an NFC or RFID chip having a unique identifier could be placedon a decedent upon intake at a funeral home. This unique identifiercould then be associated with the decedent in the database. Onceassociated, a user device could be used to read the unique identifierand, through the service, obtain the identity of the decedent. Thiscould be useful where, for example, a hairdresser is beginning toperform hairdressing services on a decedent. The hairdresser could use amobile phone or other user device to scan the RFID or NFC tag and obtainthe unique identifier, and then send this information to be received(512) by the system as part of the services start information. In thismanner, if the services are about to be performed on the wrong decedent,the mistake can be identified before the services are erroneouslyperformed. In some versions, the RFID or NFC chip could be constructedfrom heat resistant materials or placed in a heat resistant enclosureprior to being placed with or attached to the decedent. This could beuseful when the requested services are crematory services. For example,the wireless identifier could be scanned by a user device beforecremation and received (512) by the system to prevent erroneouscremations; and after cremation, the decedent's remains as well as theheat resistant wireless identifier could be placed in a container. Inthis manner, even after cremation, the wireless identifier remainsassociated with the decedent's remains and ensures an unbroken chain ofidentification.

While FIGS. 4 and 5 have been described in terms of a client requestinginformation from a vendor of goods or services, it should be understoodthat in some embodiments vendors may provide regular updates withoutfirst receiving a request. In some embodiments, unsolicited updates maybe provided based on automatic processes, such as automated processesrunning on a vendor's existing system (1008), or by way of automatedtracking of goods or service providers. In such an embodiment, a goodsuch as a concrete burial vault may have an attached iBeacon, RFID, GPSdevice, or other device which can self-locate in some manner. Forexample, if an RFID is uniquely associated with a burial vault at thetime of ordering, the RFID may be detected by an RFID reader when it isfirst attached to an ordered burial vault. It may be detected severalother times, such as when the burial vault is placed in storage andawaiting pickup, when the burial vault is picked up by a freightcarrier, and when the burial vault is dropped at a client location orburial site. Each point of detection may be logged by the system andreported to the client by an automated notification and update process,similar to those notification processes described in FIGS. 4 and 5.

Other technologies that may be used as part of the tracking, update, andnotification processes include Bluetooth low energy (“BLE”), barcodeidentification, or GEO fencing. For example, a service provider carryinga device configured to communicate with the system via BLE may triggeran update when they arrive at a location and their BLE capable devicecommunicates with a BLE capable device at the location. As anotherexample, GEO fencing could be used to track service providers carrying aGPS capable device, such as a mobile phone, as they travel to alocation. The service providers GPS capable device may communicate anupdate when the provider leaves their home location heading towards ascheduled service location, when the provider arrives at the scheduledservice location, or when a service provider fails to leave a homelocation within a time that will allow them to reach a scheduled servicelocation at the schedule time. Other implementations and uses oflocation identifying technology within the disclosed will be apparent inlight of this disclosure.

Turning now to FIG. 6, that figure shows a flowchart of a set ofexemplary high-level steps that a system could perform to manage anddisplay tasks relating to death care. The steps of FIG. 6 could beperformed by a system such as the one shown in FIG. 10, for example, andmay be interacted with by users via a user device (1014, 1016, 1018) incommunication with the Whiteboard service (1012). A brief discussion ofFIGS. 11-18 may aid in the understanding of FIG. 6, as those figuresshow exemplary interfaces for viewing and interacting with theWhiteboard service (1012) and the system of FIG. 1 via a user device(1014, 1016, 1018). FIG. 11 shows such an interface having informationaldisplays showing an event name (1100), completion percentage (1102),director (1104), visitation information (1106), weather information(1108), funeral information (1110), custom notes (1112), and dispositioninformation (1114). A history view may be accessed via an interfaceelement (1101) that would show historical information about pastclients, past tasks, past venues, past directors, and past personnel. Aninformation view, as shown in FIG. 12 may be accessed via an interfaceelement (1103) that would show more detailed information on the requiredtasks, personnel, and completion statuses.

A completion percentage (1102) is a visual or numerical representationof the overall completion status of tasks relating to a certain event(1100). Completion percentage can be calculated based upon the number ofcompleted tasks divided by the number of total tasks, or by othermethods that may result in a number representative of progress towardscompletion of all tasks. Director information (1104) identifies one ormore persons having responsibility or control over the successfulexecution of the event (1100). Visitation information (1106) shows thetype of visitation that is scheduled, the time, date and location of thevisitation, and the personnel that are associated with a visitation foran event (1100). Weather information (1108) shows the predicted weatherfor the time and date of a scheduled visitation (1106), funeral (1110),or disposition (1114). Weather information (1108) may be enteredmanually or may be configured to automatically pull from one or moreweather information providers. Funeral information (1110) shows the typeof funeral service that is scheduled, the time, date, and location ofthe funeral, and the personnel assigned to the funeral. Custom notes(1112) may be entered manually or generated automatically and may relateto a scheduled visitation (1106), funeral (1110), or disposition. Customnotes (1112) may be used to document non-standard information relatingto an event, such as, for example, a specific song to be played during avisitation, a particular design theme that should be followed for afuneral venue, or a particular route that a procession should followwhile traveling to the disposition.

Disposition information (1114) shows the type of disposition servicethat is scheduled, the time, date and location of the disposition, andthe personnel that are assigned to the disposition.

FIG. 12 shows the interface of FIG. 11 with a task list overlay thatshows a number of tasks (1200) that must be completed before an event(1100) can be completely executed. For each task (1200), a personnelassignment is shown (1202), identifying one or more persons that areprimarily responsible for completing the task. When a task is completed,an indicator (1206) can be placed signifying that the task wascompleted, as well as the time and date (1204) of completion. FIG. 13shows the interface of FIG. 11 with a custom notes (1112) overlay thatshows one or more custom notes (1302) entered by users as well as thetime and date of creation and the user that created it (1300).

FIG. 14 shows an alternate interface that is formatted for optimal useon certain user devices. An information button (1400) may be selected bya user to display the interface shown in FIG. 15. A completionpercentage (1102) and director information (1104) function similarly tothe completion percentage (1102) and director information (1104)described in FIG. 11. FIG. 15 shows visitation information (1106),funeral information (1110), disposition information (1114), custom notes(1112), and weather information (1108), which have all been previouslydescribed in relation to FIG. 11. FIG. 16 shows a number of tasks(1200), assigned personnel (1202), time and date of completion (1204),and completion status (1206), which have all been previously describedin relation to FIG. 12. FIG. 17 shows custom notes (1302) and the time,date, and author of a note (1300), which have all been previouslydescribed in relation to FIG. 13. FIG. 18 shows an interface offering anumber of filtering and searching options including a filter by newestevents or tasks (1800), filter by assigned supervisor (1802), filter byevent name (1804), filter by date (1806), or filter by location or venue(1808). The interface of FIG. 18 may be accessed via an interfaceelement (1402).

Returning to FIG. 6, basic information is received by the system (600)from a user device in order to create an event. Basic information couldinclude a name, location, date of death, contact information forsurviving family, religious preference, biographical information, orother information that may be collected when planning an event. Thesystem may then assign personnel (602) to the event, including one ormore supervisors and one or more assistants. Personnel could be assignedautomatically based upon one or more factors such as availability, workload, location, experience, familiarity with other assigned personnel,or other factors. The system may then generate visitation related tasks(604), funeral related tasks (606), and disposition related tasks (608),that may include one or more typical tasks as well as one or more uniquetasks based upon information provided upon creation of the event. Forexample, one or more typical tasks might be generated for all or mostevents, and could include tasks such as acquiring a death certificate,filing a death certificate, acquiring a burial or cremation permit, hair& makeup, reserving a visitation venue, reserving a funeral venue,scheduling a disposition date and time, and other typical tasks. Uniquetasks could include tasks based upon a specific religious belief orbiographical information of the deceased. For example, unique taskscould include a rifle salute at the disposition when biographicalinformation indicates military service or a priest delivering areligious service at the funeral when available information indicates acatholic faith. Other types of tasks generated will be apparent to oneof ordinary skill in the art in light of this disclosure.

When event and task information is available, a Whiteboard may berendered and displayed (610) via one or more user devices (1014, 1016,1018) that is based on the event and task information. The Whiteboardmay be displayed as one or more interfaces such as those shown in FIGS.11-18. While the Whiteboard is being displayed, the Whiteboard service(1012) will regularly analyze external factors (612), receive updates(614), and prioritize tasks (616). When analyzing external factors (612)the Whiteboard service (1012) may receive information relating to one ormore aspects of the event such as, for example, weather informationindicating that rain will occur during the disposition, and may reactaccordingly by adding, removing, or modifying tasks as appropriate. Forinstance, if the Whiteboard service (1012) receives informationindicating that rain will occur during an outdoor service at a cemetery,Whiteboard service (1012) may automatically push a request to thecemetery to set up a tent, provide umbrellas, and/or otherwise accountfor the rain conditions.

When receiving updates (614) the Whiteboard service (1012) may receiveinformation from personnel relating to one or more aspects of the event,such as an indication that a task was completed or an indicating that aproblem was encountered. When prioritizing tasks (616) the Whiteboardservice (1012) may regularly examine incomplete tasks and then provide avisual indicator when time sensitive tasks remain incomplete despite thepassage of time. When tasks are modified as a result of analyzingexternal factors (612), receiving task updates (614), or prioritizingtasks (616) the Whiteboard may be newly rendered and displayed (610) inorder to reflect the modifications.

Turning now to FIG. 7, that figure shows a flowchart of a set ofexemplary steps that a system could perform to receive and react toexternal event information. From time to time the Whiteboard service(1012) may receive external information that may necessitate a change toone or more tasks, or the creation or deletion of tasks. Externalinformation may arrive via one or more sources, such as weather trackingsystems, personnel systems, third party venue systems, third partyvendor systems, search engine alerts, or other sources. When an event isreceived, if it is a weather event (700) one or more tasks may beupdated (702) to accommodate for the change in weather. As an example,if weather information indicates rain during a scheduled disposition(700) a task may be created (702) to indicate that a tent should bedeployed at the disposition site to provide shelter from the rain. If areceived event is a personnel event (704) one or more tasks may beupdated to accommodate the change in personnel. For example, if a clientpersonnel system indicates that an employee has left the client companyor is unavailable due to illness (704) tasks that the employee wasresponsible for may be reassigned to other personnel (706).

If a received event is a venue event (708) one or more tasks may beupdated to address the venue event (710). For example, if a venue systemor search engine alert indicates that there is a problem with a venue(708), such as a fire that damaged the venue and made it unavailable,one or more tasks may be modified or created assigning personnel tocheck with the venue or reserve a new venue (710). If a received eventis a product event (712) one or more tasks may be modified or created toaccommodate the product event (714). For example, if an event isreceived from a vendor system indicating that an ordered concrete burialvault was damaged during transport (712), a task may be createdassigning personnel to obtaining a replacement burial vault on shortnotice (714). Once the event has been processed by the system, theWhiteboard may be rendered and displayed (610) to reflect the resultantchange. Received events could also include traffic events. For example,where an online traffic information provider indicates that there isconstruction, an accident, or perhaps a police investigation on a roadthat is part of a procession route, such information may be provided asan alert or event causing one or more tasks to be created requiringpersonnel to investigate the traffic issue and plan a new route ifnecessary. Received events could also include social media events. Forexample, social media sites such as Twitter or Facebook could beintegrated with the whiteboard service (1012) so that funeral attendeescould communicate indirectly with funeral home personnel through socialmedia. As an example, the whiteboard service (1012) could monitor aFacebook event unique to a scheduled funeral, or could monitor twitterfor a hashtag unique to a scheduled funeral, for various communicationsbetween attendees. In this manner, the whiteboard service (1012) coulddetect various events such as attendees running late, being unable toattend, traffic events, weather events, or other events that arecommonly discussed on social media. Such alerts may be automaticallyinterpreted based upon keyword identification and cause one or moretasks to be modified or created, or could be displayed on the whiteboard device (1014, 1016, 1018) unedited so that they could be manuallyinterpreted. Various other event types and behaviors exist and will beapparent in light of this disclosure.

Turning now to FIG. 8, that figure shows a flowchart of a set ofexemplary steps that a system could perform to receive and react to taskupdates. When a user completes a task or makes progress on a task, theuser may submit one or more task updates via a user device (1014, 1016,1018). If a received task update is that the task is complete (800) theWhiteboard service (1012) may validate the provided information (802) toensure that all required information has been submitted before markingthe task as complete (804). For example, if a task requiring that avisitation venue be reserved is marked as complete (800), the Whiteboardservice (1012) may validate that a valid address and phone number hasbeen provided for the visitation venue (802) before marking the task ascomplete (804) on the task completion list (1206). If a received taskupdate is providing new information but not completing a task (806), theinformation will be received (808) and associated with the task (810).For example, if a task update is received (806) for a task requiringthat a hairdresser be reserved, and the task update is that threedifferent hairdressers have been contacted for the service but none haveaccepted (808), this information will be associated with the task (810)and may be viewable as a custom note (1302). If a received task updateis that there is a problem with completing a task (812), notes relatingto the problem will be received (814) and the task will be elevated tohigher level personnel (816) that may be able to address the problem.For example, if a task problem is received (812) for a task requiringthat a death certificate be acquired, and the received problem notes(814) indicate that a doctor has refused to issue a death certificatefor some reason, the task may be assigned to the director or anothersupervisor (816) so that a person more familiar with overcoming uniqueissues that may arise can address the problem. Once the task has beenupdated to accommodate the received update, the Whiteboard may berendered and displayed (610) to reflect the modified task.

Turning now to FIG. 9, that figure shows a flowchart of a set ofexemplary steps that a system could perform to manage task prioritiesover time. While displaying the Whiteboard, one or more tasks can beprioritized based upon a required completion date and one or moredeadlines relative to the required completion date. Prioritization canbe achieved by one or more of modifying the visual display ofprioritized tasks, such as by changing the background color of a task,flashing the task, or other changes that would draw attention to thetask, by generating audio alerts such as regular chimes or other alerts,or by generating direct communication to personnel responsible for tasksas well as their supervisors to provide a reminder of the timesensitivity of the tasks. Each task may have a different requiredcompletion date as well as different deadlines, based upon the natureand complexity of the task. For example, a task requiring that flowersbe ordered might have a required date of completion twenty for hoursbefore a scheduled visitation. Since the task of ordering flower issomewhat simple, a first deadline might be thirty six hours before thevisitation, with a second deadline thirty hours before the visitation,and a third deadline twenty six hours before the visitation. For a morecomplex task, such as acquiring a burial or cremation permit, a requiredcompletion date might be the scheduled disposition date, with a firstdeadline forty eight hours before disposition, a second deadline thirtysix hours before disposition, and a third deadline twenty four hoursbefore disposition. The particular configuration of deadlines andrequired completion dates will vary based upon the particular task, withsuch variations being apparent in light of this disclosure.

While the Whiteboard is displaying tasks with configured deadlines, whena first deadline expires (900) for a task, the task will be updated toreflect a low priority (902) and responsible personnel may be notified(904) via one or more user devices (1014, 1016, 1018). Updating a taskto represent low priority (902) might include, within an interface suchas that shown in FIG. 12, displaying the task with a green backgroundcolor, increasing the font size of the task slightly, or moving the taskcloser to the top of the list. Notification of responsible personnel(904) may include a text notification, automated phone call, orapplication notification being sent to the responsible personnel (1202).When a second deadline expires (906), the task may be updated torepresent a moderate priority (908) and a personnel group rather than asingle person may be notified (910). Updating a task for moderatepriority (908) might include, within an interface such as that shown inFIG. 12, displaying the task with a yellow background color, increasingthe font size, bolding the task description, or moving the task closerto the top of the list. Notification of a personnel group (910) mightinclude notification, via a user device (1014, 1016, 1018), of one ormore personnel associated with the event. When a third deadline expires(912), the task may be updated to represent a high priority (914) andpersonnel notifications may be further elevated (916). Updating a taskto represent a high priority (914) might include, within an interfacesuch as that shown in FIG. 12, displaying the task with a red backgroundcolor, increasing the font size, causing the outline or background ofthe task to flash or blink, or moving the task to the top of the list.Elevation of notification to personnel (916) may include notifying anassigned director (1104) via a user device (1014, 1016, 1018). Once thetask has been updated to accommodate changes in priority, the Whiteboardmay be rendered and displayed (610) to reflect the modified task.

A practical example of how deadline based notifications and escalationsmay be implemented relates to preparation of the burial site, includingdigging of a hole for a burial vault, placement of chairs, flowers,walking surfaces, tents or other weatherproofing structures, and similartasks. A miscommunication or misunderstanding between a funeral home anda cemetery could result in these tasks being incomplete, misplaced, orimproperly performed on the day of a scheduled burial. With guestsarriving and a burial vault being delivered for burial, this might causean embarrassment and financial burden for the cemetery, as well asemotional suffering for the friends and family attending a burialceremony that then must be delayed or canceled. In order to preventthese types of occurrences, the disclosed system could be configuredwith escalating deadlines for important tasks or events such asrequesting that a burial site be prepared and receiving a confirmationthat the burial site has been prepared.

For example, the system could be configured with a first deadline,relative to a scheduled burial day, of one week for requesting burialsite preparation, a second deadline of 5 days, and a third deadline of 2days, or 48 hours. A set of deadlines for confirming that the burialsite has been prepared could be configured for 72 hours, 48 hours, and24 hours. With this configuration, 7 days before a scheduled burial, afirst deadline for requesting burial site preparation would be crossed(900) and the personnel responsible for the task would receive anotification (904). Then, 5 days before a scheduled burial, the seconddeadline would be crossed (906), and an escalated notification might besent to a group of personnel responsible for the task (910). Finally, 48hours before the scheduled burial (912), a final notification would besent to an elevated personnel set (916). If at any point the systemreceives an update from a user that the task is complete, subsequentdeadlines would not trigger notifications. In parallel, the system wouldadditionally send out notifications (904, 910, 916) related toconfirming that the burial site is prepared at 72, 48, and 24 hoursbefore the scheduled burial. If at any point the system receives aconfirmation from the burial site provider or cemetery that the site iscomplete, or if a user of the system submits an updated indicating thatthe burial site is complete, subsequent deadlines may not triggernotifications. Confirmation that is received from a burial site providerindicating that the burial site is prepared could include a simple textnotification, an image of the prepared burial site, GPS coordinatesindicating the location of the prepared burial site, and otherinformation that a cemetery might provide to assure a funeral home thatall required tasks have been completed.

While FIGS. 11-18 show various examples of interfaces that may bedisplayed to a user, user interfaces for the system may take otherforms. For example, FIG. 19 shows one example of an exemplary interfacethat may be displayed to a user of the system via a whiteboard (1018) orother device. The interface shows one or more client rows (1900), witheach client row having one or more associated client events (1906). Aclient row (1900) may be shown for each client for whom services arescheduled, and may contain information such as the client's name, aunique identifier, a funeral home associated with the client, a funeraldirector associated with the client (1904), and other icons, colors, orvisual styles to indicate information about a client, such as abackground image of an urn or tombstone to indicate a cremation orburial (1902). A number of client events (1906) may be created todescribe one or more events associated with the client, such as variousplanning conferences with the family of the client, a public viewing, afamily visitation, a funeral, or other events that may desirably beindividually tracked. Client events (1906) may display information suchas a description of the event, date and time of the event, an indicationof weather (1908) during the planned time of the event, identifiers forpersonnel assigned to the event (1910), an indication that furtherinformation is needed before the event information is fully populated(1912), or other information. A client event (1906) may be clicked on bya user to expand the view and show additional information, such ascustom notes or more verbose descriptions of information related to theevent. As client events (1906) are created, they may queue within theclient row (1900) in the order of the date associated with an individualevent, in an order of priority or need for additional information, or byuser configured or user specific filters or ordering schemes. Theinterface of FIG. 19 is a flexible interface for displaying clientinformation, such that any number of client events can be created andwill automatically populate the client row instead of fitting intoconcretely defined column headers. In this manner, a client could, forexample, have two visitations scheduled, or have two funerals scheduled,to allow for public and private versions of each event to be managed bythe system.

FIG. 20 shows an interface that provides expanded information for aclient row (1900) as well as additional controls related to the clientand client events (1906), and may be reached by, for example, clickingor interacting with the client row (1900). Expanded client information(2000) may provide more verbose descriptions of information associatedwith the client, such as date of birth, date of death. A family andfriends section (2006) may list the names and contact information ofparties that have been involved in planning and coordination of servicesfor the client. An events section (2008) may list information from oneor more client events (1906) in an expanded format. A case notes section(2002) may be maintained and displayed to provide additional contextthat is not more appropriately entered into a client event (1906) due tohaving a more general impact on the client services. A notificationsection (2004) may provide additional tools to allow the client to bereferred to another user of the system, or for certain client events(1906) to be referred to another user of the system, which may be usefulwhere additional information or a correction of provided information isneeded. The interface of FIG. 20 may be useful especially for a directorassigned to a specific client row (1900), as it provides a more focusedand isolated view and set of controls as opposed to the multi-clientwhiteboard view of FIG. 19.

While FIG. 10 shows one example of a system configured to providemanagement of tasks and transactions related to death care, otherconfigurations may be used, such as that shown in FIG. 21. Theconfiguration shown in FIG. 21 contemplates two entities that areprimary users of the system and access it through the Whiteboard service(1012). These primary users may vary, but often will be a funeral home(1034) and a cemetery (1036). Primary users may subscribe to theWhiteboard service (1012) at varying levels of functionality and cost.While primary users (1034, 1036) may use the Whiteboard service (1012)in any of the manners previously described, they may additionallyconfigure a whiteboard module (1020, 1024) to display the whiteboardinterfaces to one or more whiteboard displays (1022, 1026). A whiteboardmodule may be a media hub, single board computer, or other dedicatedpurpose piece of equipment that receives information from the Whiteboardservice (1012) and causes it to display on a whiteboard display (1022,1026). A whiteboard display (1022, 1026) may be a flat screentelevision, computer monitor, projector display, or other device capableof receiving a video signal and displaying it to a user. In one merelyexemplary version, a whiteboard module (1020, 1024) may be a single chipcomputer placed in a casing and configured to receive a hybrid webapplication display from the whiteboard service (1012) and output thereceived display via an HDMI connected flat panel television (1022,1026). Such a configuration allows for users to have a low cost of entryand replacement with a minimal investment in proprietary hardware, whilealso providing a system administrator the ability to troubleshoot, pushupdates, and push configurations to whiteboard modules (1020, 1024) viathe Whiteboard service (1012).

The system of FIG. 21 also allows for a number of secondary users toaccess the Connect Service (1004) via a secondary user device (1028,1030, 1032) running an application or software. Secondary users may, insome embodiments, access and use the system at no cost or within adifferent fee arrangement than primary users (1034, 1036). Secondaryusers may be service providers that provide a single good or service tothe client, most often through a primary user (1034, 1036), and mayinclude burial vault providers, hair stylists, music performers, orsimilar services and goods. In the system of FIG. 21, when a funeralhome (1034) creates client rows or client events that are associatedwith another primary user, such as a cemetery (1036), newly createdclient rows and events may be pushed, in whole or in part, via theWhiteboard service (1012) to the cemetery whiteboard display (1036).This allows for more near-immediate sharing of information for partiesthat are often working together under severe time constraints.Similarly, client events created by a funeral home (1034) that areassociated with a secondary user may be pushed, in whole or in part, tothe appropriate secondary user upon creation, via the connect service(1004) and an appropriately configured secondary user device (1028,1030, 1032).

In some embodiments, each user has one or more user devices (1014, 1016,1018) that are specifically configured for a single user, such thattasks assigned to that user are highlighted on their device andnotifications intended for that user are deliver to their device. Inother embodiments, a user device (1014, 1016, 1018) may be moregenerically configured, and may instead determine at the time ofinteraction the identity of the user. For example, where the user deviceis a mobile device (1016), the mobile device could display a generalWhiteboard view until directly interacted with by a user. Uponinteraction by a user, the mobile device (1016) could attempt toidentify the user through radio frequency identification of a card ordevice carried by that user, or by facial recognition of a user via afront-mounted camera on the mobile device (1016). Similarly, a smartboard device or display (1018) could identify users through radiofrequency identification or facial recognition via an attached camera.Once identified, the Whiteboard display could be customized for thatuser such as by highlighting tasks assigned to that user or displayingnotifications intended for that user.

While the primary users (1034, 1036) of FIG. 21 have been described as acemetery and a funeral home, and the secondary users (1028, 1030, 1032)have been described as providers of services or goods such ashairdressers, tailors, burial vault providers, music providers, itshould be understood that the classification as a primary user orsecondary user is largely a function of scale, and that an organizationthat employees many hairdressers may in some cases be better suited tointegrate with the system as a primary user (1036, 1034) with access tothe whiteboard service (1012), which offers large volume serviceproviders to integrate directly with data streams from cemeteries orfuneral homes in addition to providing a descriptive interface forrequired tasks, instead of as a secondary user. For example, if acoroner or hospital in a small city only occasionally does work with alocal cemetery or funeral home, operating as a secondary user throughthe connect service (1004) may be sufficient to meet the serviceprovider's needs. However, in a large city, where a hospital or coroneris more likely to have a high volume of interaction with funeral homesand cemeteries, their needs may be better met by interfacing with thesystem as a primary user (1034, 1036).

In some embodiments, the Whiteboard service (1012) and Connect service(1004) may operate independently of each other as disclosed above. Inother embodiments, the Whiteboard service (1012) may be in communicationwith the Connect service (1004) through the management server (1000) orvia an API, web service, or other communication method. In one suchembodiment, the Whiteboard service (1012) could provide communicationsoriginating from a Whiteboard user to the Connect service (1004), whichcould pass communications along to a vendor. The Connect service (1004)could provide communications originating from a vendor to the Whiteboardservice (1012), which could display the communications to a client. Insuch an embodiment, a Whiteboard user responsible for a task (1200)could be provided with a selectable link associated with the task (1200)that would offer options for initiating a transaction with a vendorthrough the Whiteboard service (1012). For example, if a Whiteboard userwas responsible for a task requiring that a hairdresser be scheduled,the task description could be selectable or could have an associatedbutton that, when clicked, would cause a transaction to be received(106) by the Connect service for the services of a hairdresser.Similarly, a vendor confirmation (110) received by the Connect service(1004) could be communicated to the Whiteboard service (1012) anddisplayed via the task list (1200). When receiving automated taskupdates from the Connect service (1004) in this manner, the Whiteboardservice (1012) could cause the time and date of confirmation to belogged (1204) and also mark the task as complete (1206) now that thehairdresser has been confirmed.

In yet another embodiment, when the Whiteboard service (1012) isanalyzing external factors (612) the Connect service (1004) couldprovide event updates indicating that an issue has occurred with a venue(708) or product (712). In this manner, where a task has been marked ascompleted (1206), a vendor update (116, 118) indicating that a problemhas occurred with a requested venue, service, or good could cause thetask to be updated and marked as incomplete to indicate that furtherattention is needed. For example, if the Whiteboard service (1012) wereto receive a vendor confirmation from a hairdresser, the task would bemarked as completed (1206) and may not be given any further attentionfrom assigned personnel. To continue the example, if the hairdresserwere then to become unavailable and provide a vendor update (116, 118)indicating their unavailability, the Connect service (1004) couldprovide this update to the Whiteboard service (1012) as a product event(712) that would cause the product task to be updated (714) to reflectthe fact that the task is no longer complete and another hairdressermust be reserved.

In yet another embodiment, the Whiteboard service could be configured toautomatically perform a transaction and complete a task when, forexample, the task reached a third priority deadline (912). In such anembodiment, where a Whiteboard user has configured certain preferredvendors, when a third deadline (912) passed rather than elevating thetask to supervisory personnel (916), the Whiteboard service (1012) couldinstead communicate with the Connect service (1004) such that theservice automatically receives a transaction (106) intended for thepreferred vendor. In this manner, a simple task with little variety inthe types of vendors that are used could be automatically performed bythe Whiteboard service (1012) in communication with the Connect service(1004). For example, where a Whiteboard user only has one hairdresserwhose services are used, if a task requiring that a hairdresser bereserved were to reach a third deadline (912) the Whiteboard service(1012) could generate a transaction to be received (106) by the Connectservice (1004), which would notify the hairdresser and requestconfirmation (108).

In yet another embodiment, one or more of the user devices (1006, 1010)interacting with the connect service (1004), or one or more of the userdevices (1014, 1016, 1018) interacting with the whiteboard service(1012) may have voice or gesture capture functionality that can provideadditional functionality. For example, a user device such as a mobilephone (1010) being used by a service provider such as an embalmer mayhave voice capture capabilities that would allow the embalmer to recordvoice memos that would be submitted to the system and provided to theclient as a notification. In this example, an embalmer may haveadditional information to communicate to a funeral home other than asimple verification that the process has been completed. Suchinformation could be provided by way of the voice memo, by way of textautomatically transcribed from the voice memo, or by brief verificationsbased upon keywords or phrases parsed from a voice memo.

In yet another embodiment, one or more of the user devices (1006, 1010)interacting with the connect service (1004), or one or more of the userdevices (1014, 1016, 1018) interacting with the whiteboard service(1012) may have integrated calendar functionality that is madeaccessible to the service (1004, 1012). When a device's integratedcalendar is accessible to the connect services (1004), updates fromvendors or clients may be automatically added to the calendars,providing information such as deadlines, locations, services, partiesinvolved, and other information. Additionally, when a device's calendaris accessible to the whiteboard service (1012), personnel using thedevice may have tasks that they are responsible for automatically addedto their device's calendar to provide various details relating to thetask. When user calendars are available in this manner, calendars can beused to automatically asses a services provider's or funeral homepersonnel's availability before assigning a task or reserving a service.For example, if a funeral home personnel's device calendar reports thatthey are unavailable on a certain day, the whiteboard service (1012) mayautomatically assign or reassign tasks to other personnel who areavailable.

In yet another embodiment, the management server (1000) may track,compile, manipulate, and store in the database (1002) information thatis received and sent by the connect service (1004) and whiteboardservice (1012). Such data could include original, de-identified, and/oranonymized information relating to vendors, services, goods, clients,funeral homes, directors, personnel, events, notifications, updates,visitations, funerals, dispositions, tasks, and any other informationthat passes through the services (1004, 1012) or server (1000). Originaldata may be used to optimize the performance and functionality of theservices (1004, 1012), while anonymized or de-identified data may beused to provide data to third parties to improve their own products,services, and methods. In such a way, parties relying on a particularservice or good, such as the delivery of a concrete burial vault wheretime is of the essence, can view data that may lead them to procure thevault from a vendor outside a certain region due to a high number ofdelays occurring within that region. Other uses for both original andmodified data will be apparent in light of this disclosure.

In some embodiments, the management server (1000) may be configured toexecute one or more machine learning programs or artificial intelligenceprograms, such as a neural network, in order to analyze data stored inthe database (1002) and develop the ability to predict certain events oroccurrences over time. For example, a neural network may identify that acertain personnel at a funeral home often waits until the last minute tocomplete tasks, and may modify the default notification system in orderto provide notifications for tasks 12 hours earlier than it does forpersonnel that are more timely. Over time, each input to the system,whether a traffic event, weather event, personnel specific event, clientspecific event, service provider specific event, or other informationreceived by the system from a remote server or from a user of the systemcan be used to identify output events or responses. As another example,this could include identifying the occurrence of rain at certaincemeteries during certain months and automatically generating tasks forpreparing tents or umbrellas in response. As another example, this couldinclude identifying traffic problems resulting in delays for a funeralprocession between a certain funeral home and a certain cemetery andautomatically adjusting travel times and burial ceremony times inresponse. As another example, this could include identifying serviceproviders who are consistently late in providing services, or whoprovide services that result in poor feedback from service receivers,and automatically pairing or suggesting different service providers.Other examples of reactive responses from a neural network will beapparent to one of ordinary skill in the art in light of the disclosureherein.

It should be understood that, while discussed largely in the context ofthe death care industry, many of the systems, methods, and technologyinnovations disclosed herein may be applied to other industries. Thedisclosed system is particularly suitable for industries withmulti-party transactions, such as where there is a customer that ispurchasing services and/or goods from a primary provider, where theprimary provider obtains some or all of the goods and services from oneor more secondary providers. One such example of another context mightbe automotive repair, where a customer takes a vehicle to a garage tohave damage caused by a mechanical failure or accident repaired. Inproviding the repair services to the customer, the garage may need tointerface with an insurance provider, a vehicle warranty provider, aparts provider, a detailing service, a painting service, a tireprovider, and other such secondary providers. Similar examples can befound in building construction, contract renovation and repair work,hospitals and medical care providers, veterinary care providers,commercial landscaping, and other industries. Various suitable ways inwhich the teachings herein may be applied to these other industrycontexts will be apparent to those of ordinary skill in the art in viewof the teachings herein.

Further variations on, features for, and applications of the inventors'technology will be apparent to, and could be practiced without undueexperimentation by, those of ordinary skill in the art in light of thisdisclosure. Accordingly, the protection accorded by this document, or byany related document, should not be limited to the material explicitlydisclosed herein.

What is claimed is:
 1. A system for managing events related to death care comprising: (a) a server communicatively coupled with a database; and (b) a client device comprising a display and a user input, wherein the client device is communicatively coupled with the server; wherein the server is configured to: (i) receive a set of decedent information from the client device, (ii) create a decedent entry, the decedent entry comprising a set of decedent events, based upon the decedent information, (iii) receive a director selection from the client device and associate the director with the decedent entry, (iv) for each decedent event of the set of decedent events, receive a personnel selection from the client device and associate the personnel with the decedent event, and (v) send a set of whiteboard data to the client device, wherein the set of whiteboard data comprises a set of decedent entries; wherein the client device is configured to, in response to receiving the set of whiteboard data, display a whiteboard interface, the whiteboard interface comprising a graphical display of the set of decedent entries.
 2. The system of claim 1, further comprising a service provider device, wherein the server is further configured to: (i) receive a service request from the client device via a first channel, the service request associated with a decedent event, (ii) convert the service request for transmission via a second channel, (iii) send the service request to the service provider device via the second channel, (iv) receive a service confirmation from the service provider device via the second channel, and (v) update the decedent event to indicate that the service confirmation was received.
 3. The system of claim 2, wherein the server is configured to convert, as the service request, requests for at least one of: (i) creation of a burial vault, (ii) delivery of a burial vault, (iii) makeup services, (iv) hair services, or (v) embalming services; and wherein the first channel and the second channel are each selected from the group consisting of: (i) a web based communication, (ii) a mobile application based communication, (iii) an email, (iv) a voice message, and (v) a text message.
 4. The system of claim 2, wherein the server is further configured to: (i) receive an indication that the service provider device is proximate to a service location associated with the service request, and (ii) update the decedent event to indicate that the service request is underway.
 5. The system of claim 2, wherein the server is further configured to: (i) receive an indication from the service provider device that the service request has been completed, and (ii) update the decedent event to indicate that the service request is complete.
 6. The system of claim 2, wherein the service request is for delivery of a burial vault, the system further comprising a unique identifier placed on the burial vault, wherein the service provider device comprises a global positioning device, wherein the server is further configured to: (i) receive the unique identifier from the service provider device, (ii) associate the unique identifier with the decedent event, (iii) receive a global positioning signal indicating the location of the service provider device at the time that the unique identifier was received, (iv) determine the location of the burial vault based upon the global positioning signal, and (v) update the decedent event to indicate the location of the burial vault.
 7. The system of claim 1, wherein the server is further configured to: (i) in response to the decedent event being incomplete past a first threshold date, send a notification to the personnel associated with the decedent event, and (ii) in response to the decedent event being incomplete past a second threshold date, send a notification to the director associated with the decedent entry.
 8. The system of claim 1, wherein the client device is further configured to display each decedent event of the set of decedent events proximate to a weather forecast associated with the date, time, and location of the decedent event.
 9. The system of claim 1, further comprising a personnel device, wherein the server is further configured to: (i) determine a subset of the set of whiteboard data, the subset of the set of whiteboard data comprising only the decedent entries and the decedent events that are associated with the personnel that is associated with the personnel device, and (ii) send the subset of the set whiteboard data to the personnel device; wherein the personnel device is configured to, in response to receiving the subset of the set of whiteboard data, display a personnel specific whiteboard interface, the personnel specific whiteboard interface comprising a graphical display of the subset of the set of whiteboard data.
 10. The system of claim 1, wherein the client device comprises one or more of: (i) a smart phone, (ii) a computer, or (iii) a video display.
 11. A method for managing events related to death care comprising the steps: (a) receiving, at a server, a set of decedent information from a client device; (b) creating in a database a decedent entry, the decedent entry comprising a set of decedent events, based upon the decedent information; (c) receiving a director selection from the client device and associating the director with the decedent entry; (d) for each decedent event of the set of decedent events, receive a personnel selection from the client device and associate the personnel with the decedent event; (e) sending a set of whiteboard data to a client device, wherein the set of whiteboard data comprises a set of decedent entries; and (f) at the client device, displaying a whiteboard interface, the whiteboard interface comprising a graphical display of the set of decedent entries.
 12. The method of claim 12, further comprising the steps: (a) receiving a service request from the client device via a first channel, the service request associated with a decedent event; (b) converting the service request for transmission via a second channel; (c) sending the service request to the service provider device via the second channel; (d) receiving a service confirmation from a service provider device via the second channel; and (e) updating the decedent event to indicate that the service confirmation was received.
 13. The method of claim 12, further comprising the steps: (a) receiving an indication that the service provider device is proximate to a service location associated with the service request; and (b) updating the decedent event to indicate that the service request is underway.
 14. The method of claim 12, further comprising the steps: (a) receiving an indication from the service provider device that the service request has been completed; and (b) updating the decedent event to indicate that the service request is complete.
 15. The method of claim 12, wherein the service request is for delivery of a burial vault, wherein a unique identifier is placed on the burial vault, wherein the service provider device comprises a global positioning device, further comprising the steps: (a) receiving the unique identifier from the service provider device; (b) associating the unique identifier with the decedent event; (c) receiving a global positioning signal indicating the location of the service provider device at the time that the unique identifier was received; (d) determining the location of the burial vault based upon the global positioning signal; and (e) updating the decedent event to indicate the location of the burial vault.
 16. The method of claim 11, further comprising the steps: (a) in response to the decedent event being incomplete past a first threshold date, sending a notification to the personnel associated with the decedent event; and (b) in response to the decedent event being incomplete past a second threshold date, send a notification to the director associated with the decedent entry.
 17. The method of claim 11, further comprising the step displaying each decedent event of the set of decedent events proximate to a weather forecast associated with the date, time and location of the decedent event.
 18. The method of claim 11, further comprising the steps: (a) at the server, determining a subset of the set of whiteboard data, the subset of the set of whiteboard data comprising only the decedent entries and the decedent events that are associated with the personnel that is associated with the personnel device; (b) sending the subset of the set whiteboard data to a personnel device; and (c) at the personnel device, displaying a personnel specific whiteboard interface, the personnel specific whiteboard interface comprising a graphical display of the subset of the set of whiteboard data.
 19. The method of claim 11, further comprising the step displaying each decedent event of the set of decedent events proximate to a set of traffic information for roadways associated with the location of the decedent event.
 20. A system for managing events related to death care comprising: (a) a server communicatively coupled with a database; and (b) a client device comprising a display and a user input, wherein the client device is communicatively coupled with the server; wherein the server is configured to: (i) receive a set of decedent information from the client device, (ii) create a decedent entry, the decedent entry comprising a set of decedent events, based upon the decedent information, (iii) receive a director selection from the client device and associate the director with the decedent entry, (iv) for each decedent event of the set of decedent events, receive a personnel selection from the client device and associate the personnel with the decedent event, and (v) send a set of whiteboard data to the client device, wherein the set of whiteboard data comprises a set of decedent entries; wherein the client device is configured to, in response to receiving the set of whiteboard data, display a whiteboard interface, the whiteboard interface comprising a graphical display of the set of decedent entries; and wherein the server is further configured to: (i) receive a service request from the client device via a first channel, the service request associated with a decedent event, (ii) convert the service request for transmission via a second channel, (iii) send the service request to the service provider device via the second channel, (iv) receive a service confirmation from the service provider device via the second channel, and (v) update the decedent event to indicate that the service confirmation was received; and wherein the service request is for delivery of a burial vault, and wherein the burial vault further comprises a unique identifier, wherein the service provider device comprises a global positioning device, wherein the server is further configured to: (i) receive the unique identifier from the service provider device, (ii) associate the unique identifier with the decedent event, (iii) receive a global positioning signal indicating the location of the service provider device at the time that the unique identifier was received, (iv) determine the location of the burial vault based upon the global positioning signal, and (v) update the decedent event to indicate the location of the burial vault. 